In the ever-changing world of HDL design, even these definitions are elusive. Modeling types and features that are not considered RTL become synthesizable with each new generation of tools. Behavioral models can include a range of modeling types. These include, but are not limited to:

The interrelationship of these model types in one design flow is shown in Fig. 1. The value of having different behavioral models can be seen in several places in the design process.

Behavioral models can provide an unambiguous method for communication between the system and hardware design teams in developing ICs. While the long-stated goals of using HDL models as a practical "executable specification" for a design can remain elusive, behavioral models can provide a common representation between the specifications and assumptions provided in system engineering and the requirements of the hardware design. By defining and maintaining key assertions and bounds on the design and maintaining a consistent nomenclature in the development of interfaces from the system down to the partitioned RTL models, behavioral models can be used to both drive and check a system against its original design parameters. (This methodology of course assumes a system community that is conversant in VHDL or Verilog, which is a subject for a different article.)

With the increasing presence of third-party intellectual property in many systems, behavioral models can play a key role, both in integration and determination of the appropriateness of the IP for a given requirement. The RTL of an IP block is often encrypted or mapped to hardware by a vendor to protect it or is too large or complex to be readily understood by the end users, who nevertheless still require functional models. Bus-functional and HLL-callable behavioral models are often used to provide a user with a functional representation that allows visibility into design operation. These models allow system integration and evaluation without revealing, or burdening the end user with, the internal complexity of the IP.

Behavioral models, which are perhaps the most widely used, complement RTL in verifying multiblock systems. In the testing and analysis of a design, having all the blocks integrated at an RTL can produce a logistical verification headache, especially in the typical cases when the blocks are still going through design iterations or when very large amounts of test vectors are being passed through a design. Test development and testing performance is improved when these nonsynthesizable aspects of a design are handled at a behavioral level.

Perhaps the most important consideration in developing a behavioral model is to determine what model parameters and aspects are left out. Is cycle accuracy important? Are the specific details of all the lower levels of functionality really required? Since the advantage of behavioral models lies in simplifying a design, it should be clear up front what areas in a design require simplification, and what simplifications are reasonable and appropriate for the analysis for which the behavioral models are being used.

Although in many cases behavioral modeling does not present the level of detailed complexity of an RTL model, behavioral modeling presents its own types of modeling challenges. Whereas an extensive infrastructure-including libraries, packages and utilities from both electronic design automation and silicon vendors-exists for RTL modeling to facilitate implementing a design in silicon, the support for behavioral modeling is more limited.

Some interesting efforts in behavioral modeling techniques have been developed at a number of universities [1]. Every behavioral-modeling expert seems to have his own package of functions to streamline his work-a situation that may have the potential to lead to a tower of Babel during the integration phase of a project.

Asynchronous transfer mode provides a good example of the trade-offs between behavioral and RTL modeling. At a behavioral level, ATM is fairly straightforward: Bring a packet in; read the header; and use, modify, forward or store the packet based on the packet information and system requirements.

In practice, ATM processing can be extremely complex, both because of the complexities of the processing operations and-equally as critical-because of the coding considerations for efficient implementation to silicon.

ATM systems typically consist of a number of sizable and complex blocks, including ingress and egress logic, header segmentation and reassembly operations, arbitration and quality-of-service functions, and bus interfaces. The abstract block of one such system developed recently is given in Fig. 2.

Each block structurally consisted of one or more FPGAs with external memory. The decision was made to invest in behavioral-model development in order to be able to further explore key system considerations in close synchronization with, but outside of, the critical path of RTL development of the system.

Among the key goals were the following:

These diverse requirements are difficult to address purely at the register-transfer level. By leveraging specialization and abstraction of behavioral modeling approaches, different models in an ATM design were developed with specific requirements that were to a large extent plug-and-play, since they were created in a common HDL (in this case VHDL) with a common set of I/O ports.

Each block had its own C-model description, the output of which was integrated into the design environment by a file-I/O-intensive, but otherwise simplistic, model. This C-based VHDL description was used at both ends of the design, as part of the system engineering simulations and as a key part of the verification testbench, to quickly generate large amounts of customized data traffic. Performance models of the ingress/bus control/egress path, along with their associated memory parameters, simplified the process of tracking, modifying and manipulating packets: Each packet was treated as a token, with a corresponding set of associated parameters to the packet header and payload.

Bus-functional models were developed both for the proprietary internal busing structure as well as for the external interfaces and were used to cross-reference the bus functions as implemented in the RTL models. During verification stages, the bus-functional models were also used in conjunction with data from the C-level models to create drivers for the system testbench. The availability of several types of behavioral models had an unexpected impact on the system and hardware design, analysis and verification concurrently performed by different groups. By providing a choice of model types, this had the effect of minimizing the occasions that a single model view was in the uncomfortably visible position of being held up in the critical path of the entire design.

The effort of creating a set of behavioral models for a complex system is not trivial. The potential advantages of having these models can compensate for the effort involved.

As critical as RTL design is and will remain for the near term, having supporting and corresponding behavioral models will augment the design flow by helping to improve both the performance and confidence level in the overall design process.

--

Reference
[1] Performance and Fault Modeling with VHDL, Joel Schoen ed. Prentice Hall. ISBN 0-13-658816-6.

---

Neal Stollon is principal engineer with system and hardware design consulting group HDL Dynamics (Dallas). A professional engineer, he holds a PhD in EE from Southern Methodist University. Stollon has worked at Texas Instruments, DSC Communications, Infinite Technology and LSI Logic.

http://www.isdmag.com

Copyright © 2002 CMP Media LLC
4/1/02, Issue # 14154, page 26.

Related Stories: